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1.0  EXECUTIVE  SUMMARY 


This  report  presents  an  acquisition  model  that  meets  the  needs  of  new  and  unprecedented 
systems  that  are  software  intensive,  large,  complex,  and  have  extensive  man-machine  interface 
requirements.  When  applied  properly,  it  should  reduce  the  cost,  schedule,  and  quality  risks  that 
have  been  associated  with  these  types  of  procurements.  This  model  is  proposed  within  the  context 
of  DOD-STD-2167A  and  can  be  tailored  to  apply  to  a  wide  range  of  acquisitions. 

Although  the  immediate  audience  of  this  report  is  the  Project  Manager,  all  defense 
acquisition  personnel  can  benefit  from  its  contents.  The  intent  of  this  report  is  to  characterize  a 
process  model  for  Requirements  Engineering  and  not  to  fully  specify  every  detail  for  its 
implementation. 

The  following  problems  have  adversely  affected  acquisitions:  Solicitation  and  award  of  a 
full-scale  development  contract  with  incomplete  and/or  ambiguous  requirements;  delayed 
requirements  definition  and  documentation;  the  appearance  of  contractual  relationships  that 
encourage  requirements  to  increase;  and  dynamic  operational  environments  where  requirements 
continue  to  change. 

It  is  acknowledged  that  requirements  have  not  and  perhaps  can  not  be  fully  and  adequately 
specified  up  front,  prior  to  acquisition,  especially  for  large  and  complex  systems.  Rather,  they 
evolve  throughout  the  system  life  cycle. 

This  model  stresses  that  requirements  must  be  engineered  and  managed,  no  merely 
written.  It  proposes  the  following  six  risk  reduction  strategies:  Designate  a  Requirei..ents 
Engineering  effort  which  applies  Requirements  Engineering  techniques  from  the  early  project 
phases  and  on;  contractually  decouple  requirements  definition  from  the  full-scale  development 
effort;  establish  a  functional  baseline  with  an  approved  System/Segment  Specification  prior  to  the 
solicitation  and  make  the  System/Segment  Specification  a  part  of  the  solicitation  package; 
document  the  user  interface  and  interaction  in  the  System/Segment  Specification,  together  with 
system  testing  information;  provide  structure  for  the  relationship  and  interaction  between  the  user 
and  the  full-scale  development  contractor  for  all  requirements  related  matters;  and  plan  to  develop 
systems  in  an  evolutionary  manner. 

These  strategies  have  been  previously  recommended  by  numerous  DoD  studies.  This  report 
consolidates  many  of  their  recommendations.  It  also  provides  general  guidance  for  the  Project 
Manager  on  their  implementation,  from  ‘Milestone  Zero’  through  the  fielding  of  the  last 
incremental  release,  presenting  the  responsibilities  and  relationships  of  the  primary  participants. 
Appendices  provide  additional  detail,  providing  information  for  the  acquisition  of  a  Requirements 
Engineering  effort,  a  proposed  format  and  content  of  a  Requirements  Engineering  Plan  for  a  typical 
project,  guidelines  for  the  specification  of  the  user  interface,  a  glossary,  a  bibliography,  and  a 
graphical  overview  of  this  model,  suitable  for  presentation. 


2.0  INTRODUCTION  AND  BACKGROUND  -  “WHY” 


2.1  Introduction 

This  document  presents  a  model  for  the  acquisition  of  software  intensive  battlefield 
systems.  The  model  is  intended  to  reduce  software  life  cycle  cost,  schedule  and  risks  by 
concentrating  on  improving  the  capturing  and  managing  of  requirements. 

This  section  contains  background  information  on  the  need  for  a  new  acquisition  model. 

Section  3  describes  the  model  and  provides  general  guidelines. 

Section  4  provides  criteria  for  determining  if  and  when  to  apply  this  model. 

Section  5  presents  specific  guidelines  for  the  Project  Manager  to  implement  the  model. 

Section  6  delineates  our  efforts  to  insert  the  model. 

The  appendices  provide  additional  information  for  acquisition  personnel  to  implement  this 

model. 

2.2  Background 

Modem  weapon  systems  are  software  intensive.  That  is,  they  rely  heavily  on  software  to 
provide  functionality.  These  systems  are  characterized  by  having  extensive  user  interfaces  and 
interdependence  with  other  systems.  They  are  typically  large  and  complex  and  they  operate  in  a 
dynamic  environment 

The  delineation  of  requirements  for  such  systems  is  often  incomplete,  inconsistent,  and 
specified  at  varying  degrees  of  detail,  all  of  which  significantly  contribute  to  the  risk  of  the 
development.  Some  full-Scale  Development  (FSD)  contracts  for  such  systems  are  awarded  with 
incomplete  and  ambiguous  requirements,  as  the  time  and  effort  needed  to  improve  upon 
requirements  definition  is  frequently  underestimated.  Requirement  errors  are  frequently  not  being 
discovered  until  much  later  in  the  development  and  acquisition  process,  resulting  in  cost  and 
schedule  growth.  In  addition  there  have  been  systems  for  which  the  specification  of  user  interface 
and  interaction  detail  was  delayed  until  the  critical  design  review,  making  changes  and 
improvements  very  costly  in  dollars  and  schedule. 

Currently,  FSD  contractors,  in  their  role  of  requirements  capture,  keep  the  government 
apprised  of  new  capabilities  that  can  enhance  the  system  being  developed.  The  identification  of 
these  capabilities  may  arise  either  from  new  technology  or  from  knowledge  of  the  limitations  and 
potential  of  the  system  as  it  matures.  Users  and  their  representatives  are  typically  receptive  and 
supportive  of  additional  requirements  which  they  perceive  as  providing  them  with  more  options 
and  functionality.  There  have  been  cases  where  the  FSD  contractor  was  in  the  awkward  position  of 
appearing  to  drive  up  the  system  requirements  as  a  result  of  this  relationship. 

Finally,  some  acquisitions  plan  to  develop  and  field  the  system  in  a  single  step,  not  allowing 
new  and  unforeseen  requirements  that  materialize  as  the  system  matures  to  be  easily  incorporated, 
or  uncertainties  of  risks  in  implementation  to  be  timely  dealt  with. 


2 


3.0  DESCRIPTION  OF  THE  ACQUISITION  MODEL  -  “WHAT” 


This  acquisition  model  stresses  Requirements  Engineering,  emphasizing  techniques  for 
requirements  definition  and  change  management. 

The  model  recommends  the  following  six  strategies  for  risk  reduction: 

•  Designate  a  Requirements  Engineering  effort  which  applies  Requirements 
Engineering  techniques  from  the  early  project  phases  and  on. 

•  Contractually  decouple  requirements  definition  from  the  FSD  effort. 

•  Establish  a  Functional  Baseline  (FBL)  with  an  approved  System/Segment 
Specification  (SSS)  prior  to  the  solicitation  and  make  the  SSS  a  part  of  the 
solicitation  package. 

•  Document  the  user  interface  and  interaction  in  the  SSS,  together  with  system 
testing  information. 

•  Provide  structure  for  the  relationship  and  interaction  between  the  user  and  the 
full-scale  development  contractor  for  all  requirements  related  matters. 

•  Plan  to  develop  systems  in  an  incremental,  evolutionary  manner. 

These  strategies  have  been  recommended  by  numerous  studies  and  workshops  (refer  to 
[ljthrough  [4]).  This  model  consolidates  those  recommendations  that  are  most  applicable  to  our 
software  intensive  battlefield  systems. 

While  this  model  should  reduce  the  quantity  and  severity  of  requirements  related  problems, 
it  is  not  envisioned  that  they  will  or  can  be  eliminated.  We  will  always  have  valid  needs  to  change 
requirements,  from  such  reasons  as  advances  in  technology,  changes  in  enemy  tactics  and 
capabilities,  changes  to  external  systems  which  must  be  interfaced  with,  and  insight  gained  during 
the  system  implementation. 

The  following  subsections  present  these  strategies. 

3.1  Designate  a  Requirements  Engineering  Effort  Which  Applies  Requirements  Engineering 
Techniques  from  the  Early  Project  Phases  and  On. 

Requirements  Engineering  is  the  process  of  applying  engineering  disciplines  to 
requirements  definition  and  management. 

It  is  not  sufficient  to  write  requirements.  Requirements  must  be  engineered  and  managed. 
This  model  strongly  suggests  the  early  designation  of  a  team  or  effort  that  is  responsible  for 
engineering  the  system's  requirements,  the  Requirements  Engineer  (RE). 

RE  must  wear  many  hats.  To  the  user,  the  RE  is  a  developer,  exploring  the  feasibility  and 
impact  of  their  requirements  and  then  validating  them.  To  the  Project  Manager  (PM),  the  RE  is  a 
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consultant  on  requirements  and  their  impact.  To  the  FSD  contractor,  the  RE  is  the  user,  who  seeks 
clarification  for  requirements  related  questions.  The  latter  is  bound  to  occur,  as  a  significant  amount 
of  requirements  refinement  and  clarification  occurs  during  the  software  design  phase. 

As  this  function  is  highly  technical  and  system  oriented,  it  may  be  appropriate  for  the 
project’s  system  engineer  to  be  assigned  the  lead  responsibility. 

Staffing  the  RE  team  will  be  a  non-trivial  and  critical  task.  It  is  most  advantageous  for  the 
Government  to  have  its  own  personnel  perform  this  function  directly,  and  not  through  a  contractor. 
The  Government,  itself,  must  be  the  one  who  is  the  most  aware  of  what  it  needs,  the  system 
requirements.  However,  this  may  not  always  be  feasible,  due  to  personnel  constraints,  and  it  may 
therefore  require  contractual  support. 

One  can  view  the  RE  as  having  a  role  that  is  similar  to  an  architect  of  a  building  project 
[5].When  constructing  a  building,  we  prefer  to  consult  with  the  expert  and  independent  architect 
regarding  our  needs  and  desires,  not  construction  contractors,  who  may  have  expertise,  but  who 
also  benefit  from  the  new  work  that  requirements  generate. 

The  RE  should  be  under  the  control  and  direction  of  the  PM  and  the  effort  should  be 
initiated  prior  to  the  FSD  solicitation  with  the  immediate  goal  of  enhancing  the  FSD  procurement 
package. 

From  the  earliest  acquisition  planning  phases,  adequate  time  must  be  allocated  for  the  RE 
effort.  The  effort,  itself,  must  begin  no  later  than  the  initial  drafts  of  the  Operational  and 
Organizational  Plan  and  Required  Operational  Concept  documents,  early  on  in  the  project  and 
before  commitments  by  Government  and  contractors  are  made. 

Although  this  report  is  not  a  tutorial  on  Requirements  Engineering,  it  should  be  noted  that 
the  RE  has  a  host  of  tools  and  techniques  at  his  disposal  to  symbolically  construct  aspects  of  a 
system  and  effectively  derive  and  validate  the  requirements.  Technology  provides  the  capability  to 
quickly  generate  sample  screens,  interactions,  and  representative  usage  of  a  proposed  system.  We 
refer  to  this  technique  as  prototyping.  We  also  include  simulation  and  modelling  in  our  definition 
of  prototyping. 

Prototyping  can  be  effectively  used  to  test  the  feasibility  of  both  user  requirements  and 
possible  implementations.  Prototypes  can  be  generated  to  capture  and  examine  user  interface  and 
other  external  interface  requirements,  communication  protocols,  functional  operations,  conditions, 
constraints,  and  performance.  Prototyping  can  be  used  to  perform  trade-off  studies.  Prototyping 
may  also  shed  light  on  total  system  acquisition  costs.  Finally,  symbolic  construction  typically 
involves  designing  the  symbolic  system,  where  invaluable  insight  on  the  requirements  and  their 
allocation  for  the  real  system  is  derived. 

There  is,  however,  a  major  pitfall  with  rapid  prototypes.  Although  quick,  they  are  also 
‘dirty.’  That  is,  they  are  not  always  engineered  in  a  way  that  is  efficient  or  easily  maintainable 
(fixable  and  changeable).  The  FSD  effort  is  engineered  properly,  but  the  user  has  to  wait  for  it.  A 
common  occurrence  when  a  prototype  provides  or  appears  to  provide  needed  capabilities  is  that 
the  user  wants  to  field  it  immediately.  The  PM  must  make  it  clear  to  all  who  have  a  stake  in  the 
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system,  the  stakeholders,  that  the  use  of  a  poorly  engineered  prototype  in  actual  fielded  applications 
is  not  recommended,  nor  can  such  a  system  be  supported. 

Reference  is  provided  [6]  for  additional  information  on  prototyping  and  other 
Requirements  Engineering  techniques. 

This  model  recommends  that  the  RE  be  involved  with  requirements  related  issues 
throughout  the  lifetime  of  the  project,  not  just  during  its  early  stages.  During  system  development, 
the  RE  should  interact  with  the  Combat  Developer  (CD)  regarding  proposed  changes  to  the 
baseline.  The  RE  should  interact  with  end  users  after  initial  system  fielding  to  gain  their  feedback. 
Relevant  activities  include:  prototyping  to  define  or  refine  requirements  for  future  blocks;  risk  and 
feasibility  analysis;  trade-off  studies;  requirements  change  impact  analysis;  tracing  requirements 
between  documents;  maintaining  the  consistency  of  requirements  documents;  verification  that 
requirements  are  being  met  by  the  developer,  and  supporting  the  PM  during  reviews  and  audits. 

The  PM  must  carefully  assess  the  requirements  for  the  Requirements  Engineering  effort 
and  then  monitor  it  carefully.  Just  as  with  the  FSD  effort,  the  risk  of  requirements  proliferation 
exists.  Unlike  the  FSD  effort  though,  this  effort  is  on  a  much  smaller  scale,  reducing  risk  impact. 

3.2  Contractually  Decouple  Requirements  Definition  from  the  Full-Scale  Development 
Effort. 


Requirements  are  a  major  driving  force  in  acquisition  cost  and  scnedule.  They  should, 
therefore,  be  engineered  by  an  independent  agent,  the  RE,  and  not  by  the  FSD  contractor  who 
stands  to  gain  additional  work  from  additional  requirements. 

A  RE  contractor  should  therefore  be  precluded  from  the  FSD  competition  and 
subcontracting. 

The  FSD  contractor  should  only  be  responsible  for  activities  beginning  with  software 
requirements  analysis.  This  strategy  would  insure  that  the  design  effort  commences  with  a  well 
stated  set  of  requirements. 

To  minimize  the  learning  curve  for  the  FSD  contractor  to  become  familiar  with  the  system’s 
requirements,  industry  should  be  kept  informed  of  the  acquisition  potentials  of  the  system  at  the 
earliest  possible  time.  They  should  also  be  provided  with  drafts  of  all  releasable  requirements 
documents,  as  they  become  available,  as  well  as  prototypes,  if  appropriate.  In  the  past,  comments 
received  from  industry  during  this  stage  have  proven  to  be  invaluable  for  many  projects. 

33  Establish  a  Functional  Baseline  with  an  Approved  Svstem/Segment  Specification  Prior 
to  Solicitation  and  Make  the  Specification  a  Part  of  the  Solicitation  Package. 

Solicitation  and  award  of  the  FSD  contract  without  a  firm  understanding  and  agreement 
with  the  CD  and  all  stakeholders  on  the  requirements  will  lead  to  a  contract  that  lacks  firm  (or  any) 
cost  and  schedule  commitments. 

The  recommended  strategy  is  to  have  the  RE  write  the  SSS  and  conduct  the  System 
Requirements  Review  prior  to  the  solicitation.  The  approved  and  validated  SSS  would  then  come 
under  Government  configuration  control  and  become  part  of  the  FBL.  The  SSS  should  also  become 
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a  part  of  the  solicitation  package.  In  doing  so,  we  will  know  what  we  are  buying  and  bidders  will 
know  what  we  really  want. 


This  approach  does  not  eliminate  the  possibility  of  changing  the  requirements  during  the 
solicitation  period  and  during  the  development,  with  controlled  revisions  of  the  SSS.  However,  it 
does  reduce  some  of  the  opportunities  for  changes  with  serious  impact  to  occur. 

3.4  Document  the  User  Interface  and  Interaction  in  the  Svstem/Segment  Specification, 
together  with  system  testing  information. 

As  mentioned  previously,  user  interface  and  interaction  details  are  rarely  agreed  upon  in  a 
timely  manner.  This  greatly  impacts  cost  and  schedule.  Section  3.2.3  of  the  SSS  format  describes 
the  interfaces  with  external  systems.  This  is  an  ideal  place  to  provide  detail  on  the  man-machine 
interface  and  interaction  from  the  user-perspective  of  the  system.  A  detailed  breakdown  of  the 
information  that  is  needed  for  this  section  is  provided  in  Appendix  D. 

It  should  be  noted  that  section  4.0  of  the  SSS  deals  with  provisions  for  quality  assurance. 
Test  case  requirement  coverage  and  general  system  test  philosophy  should  be  specified  by  the  RE 
in  this  section.  Additionally,  the  RE  may  be  asked  to  specify  the  system  requirements  test  plan  and 
cases  in  separate  documents.  For  some  developments,  it  may  be  appropriate  for  the  RE  to  support 
or  actually  perform  the  testing. 

3.5  Provide  structure  for  the  relationship  and  interaction  between  the  user  and  the  full-scale 
development  contractor  for  all  requirements  related  matters. 

As  mentioned  previously,  the  relationship  between  the  FSD  contractor  and  the  user  can 
unknowingly  contribute  to  requirements  growth.  This  model  recommends  that  the  user/  FSD 
interaction  be  restricted  to  the  point  where  there  is  no  appearance  of  a  conflict  of  interest.  For 
example,  the  contractor  should  be  restricted  from  picking  up  the  phone  and  suggesting  new 
requirements  directly  with  the  user.  Rather,  the  user  and  the  contractor  should  interact  with  the  PM 
and  RE. 

As  the  expert  on  the  system  requirements,  the  RE  is  a  competent  representative  and 
advocate  for  user  needs  to  the  developer.  As  an  expert  on  system  development,  the  RE  is  able  to 
evaluate  feasibility  and  discuss  technical  concerns  with  the  user. 

The  CD  should  be  an  active  participant  in  the  system’s  formal  reviews.  These  reviews 
provide  a  formal  and  controlled  environment  for  user-developer  interaction.  Understandably, 
interactions  such  as  end  user  evaluation  at  the  contractor  site  should  not  be  precluded. 

3.6  Plan  to  Develop  Systems  in  an  Incremental.  Evolutionary  Manner. 

Our  battlefield  systems  are  often  too  dynamic  and/or  complex  to  field  successfully  in  a 
single  release.  It  is,  therefore  very  difficult  to  plan  for  a  system’s  development  in  one  release,  or 
block. 
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Plans  for  the  development  should  call  for  incremental  releases  of  the  system.  It  is 
recommended  that  users  prioritize  their  requirements,  listing  and  rating  them  by  need  and  by 
certainty.  Requirements  that  are  certain,  well  understood  and  that  are  critical  to  user/system 


functionality  should  be  met  in  the  initial  release.  These  requirements  should  be  specified  in  detail 
in  the  body  of  the  SSS.  This  initial  system  must  be  useful  to  the  user,  providing  essential 
capabilities,  albeit  it  is  not  everything  that  is  needed. 

Requirements  for  subsequent  releases  must  also  be  documented  in  the  SSS.  They  can  be 
stated  in  separate  appendices  and  at  this  point,  do  not  need  the  great  detail  of  the  initial  release’s 
requirements. 

Requirements  for  subsequent  releases  can  become  separate  options  on  the  FSD  contract  or 
they  can  be  separate  procurements,  depending  on  the  system. 

As  the  RE  completes  work  on  a  block,  the  RE  should  continue  to  interact  with  the  CD  and 
all  system  stakeholders  to  refine  and  document  requirements  for  subsequent  blocks.  The  end  user 
must  provide  the  RE  with  feedback  from  his  experience  with  blocks  already  in  the  field. 

Just  as  with  the  initial  release,  subsequent  releases  must  be  completely  defined,  validated 
by  all  stakeholders,  and  baselined  before  commitments  are  made  to  implement  them. 
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4.0  MODEL  APPLICABILITY  -“WHEN” 


This  section  presents  the  characteristics  of  systems  that  would  most  benefit  from  applying 
the  strategies  of  this  model.  Any  one  of  these  characteristics  can  be  sufficient  to  warrant  the  use  of 
this  model.  The  model  can  also  be  tailored,  applying  some  of  its  six  strategies  to  broaden  its 
relevance. 

As  an  example,  a  new  and  complex  Command  and  Control  system  would  benefit 
significantly  from  the  application  of  this  model  to  its  acquisition. 

4.1  Medium  to  Large  Size. 

Systems  that  are  expected  to  exceed  50,000  source  lines  of  code  usually  require  lengthy 
development  schedules,  significant  investment  in  resources  (funding,  managem:  M  attention,  and 
manpower),  extensive  design  efforts,  and  prolonged  test  and  evaluation  programs.  The  potential 
for  overruns  due  to  faulty  or  deficient  system  requirements  in  these  programs  warrants  the  use  of 
this  model  to  reduce  the  technical  risk  and  shorten  the  development  schedule  through  advanced 
requirements  definition  techniques  prior  to  FSD. 

4.2  Complex  Functionality. 

When  a  system  has  complex  functions,  there  is  a  very  high  risk  of  cost  and  schedule  growth 
unless  the  requirements  are  defined  prior  to  FSD  to  the  fullest  possible  degree.  Complexity  can 
come  from  having  a  large  number  of  user  options  or  having  a  large  number  of  external  interfaces. 
It  can  also  come  from  the  internal  complexity  of  the  software  needed  to  satisfy  the  functional 
requirements.  This  model  recommends  the  application  of  Requirements  Engineering  technologies 
to  better  understand  and  specify  system  requirements. 

4.3  Intensive  Man-Machine  Interface. 


Without  hands-on  user  involvement,  it  is  difficult  to  specify  and  validate  the  requirements 
for  systems  that  have  complex,  user-dependent,  man-machine  interfaces.  This  model  recommends 
rapid  prototyping  and  the  early  documentation  of  the  user  interface  and  interaction. 

4.4  Unprecedented  Systems. 

Systems  which  are  being  developed  to  provide  capabilities  that  have  not  been  previously 
available  would  benefit  greatly  from  this  model.  As  the  delivery  of  the  system  will  probably  change 
the  operational  environment,  users  need  to  work  with  prototypes  early  on,  to  understand  potential 
applications  and  impacts. 
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5.0  PROJECT  LEVEL  MODEL  IMPLEMENTATION  -  “HOW” 


This  section  provides  the  PM  with  additional  guidance  on  applying  the  acquisition  model. 
This  is  divided  into  four  time  frames: 

•  Milestone  0  to  Requirements  Engineering  Task  Initiation. 

•  Requirements  Engineering  Task  Initiation  to  Release  of  the  FSD  Request  For 
Proposal  (RFP). 

•  FSD  RFP  Release  to  Contract  Award. 

•  FSD  Contract  Award  to  Final  Block  Deployment. 

This  model  proposes  no  changes  to  procurement  strategies  before  Milestone  0. 

Each  of  the  following  sections  identifies  the  model  activities  during  these  phases  and 
presents  responsibilities  and  relationships  of  the  primary  participants. 

5.1  Milestone  0  to  Requirements  Engineering  Task  Initiation 

After  Milestone  0,  the  PM  prepares  an  Acquisition  Plan,  based  on  risk  analysis,  which 
addresses  the  degree  that  the  model  will  be  utilized  and  the  needs  for  Requirements  Engineering. 
The  plan  should  include: 

•  The  block  release  approach. 

•  A  scope  and  strategy  for  Requirements  Engineering. 

•  A  proposed  source  for  the  Requirements  Engineering  expertise,  either  in-house 
or  contract. 

If  a  Requirements  Engineering  contractor  is  needed,  a  cost  reimbursable  type  contract  is 
recommended  because  the  tasks  for  this  effort  are  difficult  to  predict.  Appendix  A  contains 
guidance  for  acquiring  a  Requirements  Engineering  contractor.  Appendix  B  contains  technical 
content  for  a  Requirements  Engineering  Statement  of  Work.  The  latter  can  also  be  used  when  the 
Requirements  Engineering  is  being  done  by  Government  personnel. 

Prospective  bidders  should  be  requested  to  document  their  approach  in  a  Requirements 
Engineering  Plan.  After  contract  award,  the  Requirements  Engineering  Plan  should  become  part  of 
the  contract.  A  proposed  format  and  content  of  this  plan  is  provided  in  Appendix  C. 

Responses  to  a  Requirements  Engineering  RFP  should  be  evaluated  based  on  the  bidder’s 
understanding  of  the  technical  and  operational  characteristics  of  the  objective  system,  the 
candidate’s  expertise  in  Requirements  Engineering,  and  his  relevant  experience  in  system 
development. 
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5.2  Requirements  Engineering  Task  Initiation  to  Full  -Scale  Development  Request  for 
Proposal  Release 

The  goal  of  this  phase  is  to  produce  a  high  quality  FSD  procurement  package,  with  clearly 
specified  requirements  and  a  FBL,  documented  by  a  SSS. 

Under  the  direction  and  control  of  the  PM,  the  RE  develops  the  FBL.  The  PM,  together  with 
the  RE,  must  identify  the  areas  of  requirements  related  risk.  From  this  analysis,  the  Requirements 
Engineering  Plan  may  need  to  be  revised  in  order  to  identify  the  portions  of  the  system  that  need 
to  be  studied,  the  techniques  that  should  be  used,  and  who  should  review  the  products.  The  PM 
must  insure  a  disciplined  flow  of  information  between  the  program  participants  and  that  all 
requirements  related  information  is  well  documented  and  transferrable.  The  PM  must  evaluate  the 
evolving  requirements,  providing  guidance  to  the  RE  through  frequent  interaction  and  in-progress 
reviews. 

It  is  recommended  that  the  PM  keep  industry  apprised  of  the  developing  RFP,  providing 
them  drafts  of  requirements  related  documents  and  products,  as  appropriate,  as  well  as  a  draft  RFP. 
Care  must  be  taken  to  give  equal  access  and  opportunities  to  all  prospective  bidders. 

The  RE  must  engineer  the  requirements,  refining  and  transforming  the  requirements  from 
a  broad  Mission  Needs  Statement  to  a  validated  FBL.  In  addition,  the  RE  must  insure  that  the 
requirements  are  feasible,  consistent  and  testable.  Using  the  best  available  Requirements 
Engineering  technology,  the  RE  interacts  with  the  CD  and/or  end  user  in  an  iterative  fashion,  until 
the  requirements  are  clarified,  validated,  and  refined  for  a  quality  SSS. 

In  all  likelihood,  the  first  release  will  have  some,  but  not  all,  of  the  functionality  that  the 
end  users  requested.  The  PM  must  work  carefully  with  the  RE  and  all  stakeholders  as  they 
prioritize  requirements  for  the  initial  release.  The  following  factors  relating  to  a  requirement  should 
be  considered: 

•  Criticality. 

•  Desirability  to  the  user. 

•  Implementation  risk. 

The  block  release  strategy  must  be  reflected  in  the  SSS.  The  body  of  the  SSS  should  focus 
on  the  initial  release.  All  subsequent  block  releases  must  be  planned,  specified  in  as  detailed  a 
manner  as  is  possible,  and  incorporated  into  appendices  of  the  SSS.  All  requirements  in  the  SSS, 
as  well  as  proposed  incremental  versions,  must  be  documented  and  clearly  traceable  to  source 
documents. 

The  SSS  is  formally  validated  through  the  Systems  Requirements  Review,  per  DOD-STD- 
2167A.  This  review  should  be  hosted  by  the  RE,  who  authored  the  SSS.  Once  accepted,  the  SSS  is 
placed  under  configuration  control. 

The  validated  SSS  becomes  part  of  the  FSD  RFP,  enhancing  the  procurement  package  and 
providing  confidence  for  the  commitment  of  resources  needed  to  build  the  system. 
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The  CD  supports  both  the  PM  and  the  RE  by  providing  expertise  or  actual  end  users  to 
meet  the  Requirements  Engineering  needs.  The  CD  must  review  the  FSD  RFP. 

5.3  Full-Scale  Development  Request  for  Proposal  to  Contract  Award 

To  maintain  procurement  integrity,  the  SSS  must  be  frozen  before  the  FSD  RFP  is  issued. 
In  a  dynamically  changing  world,  this  is  not  always  possible  and  user  needs  may  dictate  a  pre¬ 
award  revision.  Also,  the  Government  may  receive  valuable  insight  from  comments  from  the 
bidders.  If  possible,  changes  should  be  relegated  for  inclusion  in  later  incremental  blocks.  If 
changes  are  mandated,  all  bidders  must  be  given  sufficient  time  after  receipt  of  the  updated 
specification  to  submit  their  ‘Best  and  Final  Offer.’ 

Once  Block  One  requirements  have  been  baselined,  the  RE  can  begin  defining  and  refining 
requirements  for  subsequent  incremental  blocks,  repeating  the  process  used  in  the  identification  of 
the  Block  One  requirements. 

5.4  Contract  Award  to  Final  Block  Deployment 

During  this  phase,  the  RE  tasks  during  this  period  include  interacting  with  system 
stakeholders  and  the  FSD  contractor,  supporting  the  initial  block’s  development,  and  supporting 
the  development  of  future  blocks. 

When  discussing  requirements  with  a  stakeholder,  the  RE  must  play  the  role  of  the  FSD 
contractor  and  evaluate  requirements  feasibility  and  impact,  consulting  and/or  involving  the  FSD 
contractor  as  necessary.  The  RE  should  then  provide  the  PM  with  a  recommendation  and  an 
implementation  approach.  If  this  new  or  changed  requirement  is  approved,  the  RE  should 
document  it  as  an  Engineering  Change  Proposal. 

To  the  developing  contractor,  the  RE  is  the  surrogate  user,  answering  requirements  related 
questions  and  seeking  clarification  from  the  CD  when  necessary. 

If  the  FSD  contractor  differs  with  the  RE,  then  the  PM  will  make  the  final  decision. 

The  RE  can  support  the  PM  in  the  same  areas  that  were  suggested  for  Block  One.  Because 
the  RE  has  an  in-depth  understanding  of  the  system  specifications  and  the  development  rationale, 
the  PM  can  use  this  knowledge  to  aid  in  overseeing  the  FSD  effort.  The  PM  can  use  the  RE  to  assist 
in  ensuring  that  the  system’s  requirements  are  being  met.  The  RE  may  provide  support  during 
reviews  and  may  review  draft  contract  data  requirements  list  items.  The  RE  can  also  be  tasked  to 
trace  the  evolving  requirements  to  source  documents.  The  RE  may  provide  technical  support  to  the 
project’s  Configuration  Control  Board  to  review  proposed  changes.  The  RE  may  prepare  the  plans 
and  test  cases  for  acceptance  testing  and  perform  the  tests. 

Future  releases  incorporate  specific  requirements  which  have  been  identified  in  the  initial 
SSS  and  deferred  to  a  later  release.  They  also  include  requirements  that  are  changes  to  the  initial 
baseline,  resulting  from  lessons  learned  from  fielded  releases.  The  RE  should,  therefore,  solicit  and 
record  user  feedback  on  their  experience  with  the  fielded  releases. 

Engineering,  specification,  and  validation  of  the  requirements  for  later  block  releases 
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proceeds  in  the  same  fashion  as  the  first  release.  However,  later  blocks  have  the  added  constraint 
that  the  change  must  be  compatible  with  fielded  blocks. 

When  a  proposed  block  FBL  has  been  sufficiently  defined,  the  RE  should  host  a  new  SRR 
for  it.  This  review  should  address  new  requirements,  changes  to  old  requirements,  and 
compatibility  issues  between  blocks. 

The  RE  should  be  responsible  for  reflecting  the  evolution  of  the  system  by  revising  the  SSS, 
using  Engineering  Change  Proposals,  providing  additions  and  modifications  to  the  sections  that 
refer  to  the  future  blocks. 

The  PM  must  decide  how  new  incremental  blocks  should  be  acquired.  The  existing  FSD 
contract  may  make  provisions  for  a  block  approach.  Or,  the  contract  may  be  modified,  based  upon 
new  costs  and/or  schedules.  Alternatively,  a  new  contract  could  be  awarded  competitively.  The 
existence  of  a  RE  gives  the  PM  a  resource  to  help  him  proceed  with  any  of  these  strategies.  Further, 
the  RE  can  assist  in  the  development  of  the  necessary  procurement  documents. 
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6.0  EFFORTS  TO  PROMOTE  THE  MODEL  AND  GAIN  ITS  ACCEPTANCE 


The  acquisition  model  presented  in  this  report  proposes  a  small  change  to  the  current 
acquisition  process.  Current  policies,  regulations,  and  standards  do  not  preclude  the 
implementation  of  this  model,  but  they  do  not  encourage  it,  either. 

A  step-by-step  approach  is  planned  to  gain  recognition  and  acceptance  of  the  strategies  in 
this  model.  Our  near  term  goal  is  for  the  model  to  be  implemented  and  validated  on  a  pilot  project 
at  the  US  Army  Communications/Electronics  Command  (CECOM),  monitoring  and  reporting  the 
technical  and  financial  benefits  provided  by  it  on  the  program. 

In  addition,  we  have  prepared  a  Requirements  Engineering  tutorial  to  brief  CECOM  and 
PEO/PM  organizations  on  the  advantages  and  features  of  this  model. 

We  also  plan  to  use  existing  Defense  Industry  associations  and  trade  journals  to  disseminate 
the  model  and  its  effect  on  the  system  development  process.  These  associations  provide  an 
effective  medium  for  educating  industry  and  also  provide  a  forum  to  obtain  industry  review  and 
comment  on  this  model. 

Finally,  CECOM  Center  for  Software  Engineering  (CSE)  is  serving  as  CECOM ’s  focal 
point  for  Requirements  Engineering  related  research,  development,  and  implementation.  As  such, 
the  CECOM  CSE  would  provide  the  necessary  support  in  implementing  this  model. 
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Appendix  A 


CONSIDERATIONS  FOR  PREPARING  A  REQUIREMENTS 
ENGINEERING  CONTRACT  PROCUREMENT  DATA  PACKAGE 

This  appendix  provides  information  to  aid  a  Project  Manager  for  the  preparation  of  a 
Requirements  Engineering  contract’s  Procurement  Data  Package.  It  provides  guidance  for 
requesting  relevant  proposal  data  from  bidders.  It  also  provides  considerations  for  evaluation 
approach.  This  appendix  is  not  intended  to  be  a  sample  Procurement  Data  Package,  as  contractual 
guidance,  content,  formats,  and  legal  interpretation  vary  between  acquisition  agencies. 

A.l  Relevant  Proposal  Data 

A.  1.1  General  Considerations 

In  their  technical  proposal,  bidders  must  be  asked  to  demonstrate  competence  and  a  detailed 
understanding  of  the  mission  environment  of  the  objective  system.  Requirements  Engineering,  and 
software  engineering. 

The  contractors  must  identify  their  experience  in  working  with  other  systems  in  the  same 
general  mission  area  as  the  objective  system.  This  experience  need  not  specifically  involve 
requirements  derivation.  The  purpose  of  the  mission  area  experience  is  to  guarantee  a  familiarity 
with  the  environment,  terminology,  and  philosophy  of  the  intended  system. 

Prospective  contractors  should  be  asked  to  cite  specific  experience  in  using  Requirements 
Engineering  tools,  techniques,  and  methodologies  for  the  development  of  the  requirements  of 
tactical  software  systems.  They  must  identify  specific  projects  in  which  this  experience  was  used. 
They  must  identify  those  tools  with  which  they  have  specific  experience  and  that  are  available  to 
support  the  Requirements  Engineering  process. 

They  should  demonstrate  their  understanding  of  Requirements  Engineering  techniques  by 
discussing  perceived  advantages  and  trade-offs  associated  with  different  Requirements 
Engineering  approaches  and  techniques,  as  related  to  the  objective  system. 

The  contractors  should  outline,  categorize,  and  discuss  potential  aspects  of  risk  of  the 
objective  system  development  and  present  their  approach  to  deal  with  them. 

Bidders  should  be  asked  to  provide  a  plan  for  staffing  the  Requirements  Engineering  effort. 
This  plan  should  identify  key  technical  and  management  personnel.  Key  individuals  should  be 
committed  to  participation  in  the  effort  more  than  50  percent  of  their  time  and  should  not  be 
replaced  before  90  days  after  award.  Resumes  should  be  included  for  all  key  personnel.  These 
resumes  should  fully  document  the  individual’s  education  and  specific  experience  which  is 
relevant  to  the  effort.  This  staffing  plan  must  include  the  bidder’s  approach  for  obtaining  and 
assigning  non-key  personnel  for  the  project. 


The  bidder’s  management  proposal  should  cover  the  corporate  and  project  management 
structure  that  will  be  in  effect  during  the  effort,  including  responsibilities,  access  to  resources, 
quality  assurance  procedures  and  subcontract  management. 

A.  1.2  Possible  Draft  Deliverables 

Each  respondent  may  be  asked  to  submit  draft  CDRL  items  with  their  proposal.  These 
sample  deliverables  provide  insight  into  the  contractor’s  understanding  of  the  requirements  of  this 
effort.  They  also  provide  an  insight  regarding  the  contractor’s  capabilities  as  a  RE.  As  the 
Government  does  not  compensate  prospective  bidders  for  proposal  preparation  costs,  the 
Government  must  keep  this  requirements  to  a  minimum. 

A.  1.2.1  Requirements  Engineering  Plan. 

The  Requirements  Engineering  Plan  documents  the  approach  that  the  contractor  will  take 
to  identify,  document,  and  validate  the  requirements  of  the  objective  system,  identifying  all 
activities,  schedules,  tools,  and  resources  that  will  be  used  in  the  requirements  engineering  process. 

The  format  and  content  of  a  Requirements  Engineering  Plan  is  provided  in  Appendix  C  of 
this  report.  This  document  should  become  a  part  of  the  Requirements  Engineering  contract  upon 
its  award. 

A.  1.2.2  Requirements  Engineering  Notebook  Format. 

Requirements  Engineering  Notebooks  document  the  underlying  source  and  rationale  of  the 
system  requirements,  providing  the  PM  with  an  audit  trail  from  the  requirements  sources  to  the 
Requirements  Engineering  products  and  activities.  The  contractors  would  propose  a  structure  and 
format  for  these  notebooks. 

A.  1.2.3  Configuration  Management  Plan. 

The  Configuration  Management  Plan  specifies  how  the  contractor  will  maintain  his 
developmental  baseline  control  of  requirements  and  prototypes  until  such  time  as  the  specifications 
are  turned  over  to  the  Army  for  formal  configuration  control.  The  contractors  would  provide  a  draft 
of  this  plan. 

A.2  Proposal  Evaluation 

A.2.1  Government  Evaluation  Team 

The  Government  must  ensure  that  a  qualified  team  is  available  to  support  the  evaluation  of 
the  Requirements  Engineering  proposals.  Individuals  on  this  team  should  have  experience  in  the 
mission  area  of  the  objective  system,  Requirements  Engineering,  and  software  engineering.  If  such 
individuals  are  not  available  within  the  PM’s  organization,  then  the  PM  must  draw  support  from 
other  organizations  for  the  procurement  process. 
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A.2.2  Selected  Evaluation  Considerations 


The  following  should  be  considered,  at  a  minimum,  when  planning  for  the  evaluation: 
Technical: 


•  Demonstration  of  the  contractor’s  understanding  and  experience  in  the  mission  area  of 
the  objective  system.  This  should  include  a  demonstration  of  the  contractor’s 
understanding  of  the  risk  areas  associated  with  the  objective  system  and  an  appropriate 
plan  for  mitigating  those  risks. 

•  Demonstration  of  the  contractor’s  understanding  and  experience  in  Requirements 
Engineering.  This  should  include  the  adequacy  and  appropriateness  of  the  proposed 
Requirements  Engineering  methodology  for  the  objective  system. 

•  Demonstration  of  the  contractor’s  understanding  and  experience  in  software  engineering. 

•  Adequacy  of  the  requested  sample  deliverables. 

•  Hardware  and  software  resource  availability  to  perform  the  work. 

•  Demonstration  of  the  contractor’s  capability  to  write  clearly,  unambiguously,  and 
concisely. 

Personnel: 

•  Key  and  supporting  personnel  availability  who  are  qualified  in  the  objective  system 
mission  area.  Requirements  Engineering,  and  software  engineering. 

•  Realism  and  adequacy  of  staffing  plan  for  non-key  personnel. 

Management: 

•  Effectiveness  of  project  organizational  structure  and  management  approach  in  controlling 
cost  and  schedule,  and  insuring  quality. 

•  Adequacy  and  feasibility  of  plan  for  acquiring  supplementary  resources,  such  as 
subcontractors,  if  subcontractors  are  proposed 

•  Adequacy  of  the  quality  assurance  approach. 
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Appendix  B 


TECHNICAL  CONTENT  FOR  A  STATEMENT  OF  WORK  FOR 
REQUIREMENTS  ENGINEERING  SUPPORT 


This  appendix  provides  technical  content  for  a  Statement  of  Work  for  a  Requirements 
Engineering  contractual  effort.  This  appendix  was  not  written  to  be  a  sample  RFP,  as  contractual 
guidance,  content,  formats,  and  legal  interpretation  vary  between  acquisition  agencies. 

The  developing  agency  is  referred  to  as  [Agency].  The  name  of  the  objective  system  is 
referred  to  as  [System]. 

This  appendix  was  written  as  broadly  as  possible,  including  as  many  Requirements 
Engineering  functions  as  possible.  It  may  be  tailored  to  apply  to  a  wide  range  of  acquisitions. 

B.l  General  Requirements 

The  RE  shall  be  responsible  for  the  development,  refinement,  validation,  documentation, 
traceability,  and  management  support  of  the  [System]  system  requirements  and  their  evolution.  He 
shall  interact  with  the  Program  Manager  (PM),  the  Combat  Developer  (CD),  the  Full-Scale 
Development  Contractor  (FSDC),  and  all  system  stakeholders.  The  RE  shall  be  responsible  for  the 
preparation  of  the  Systems/Segment  Specification  (SSS)  and  the  System  Requirements  Review. 
The  SSS  shall  fully  describe  the  user  interface  and  interaction  needs  of  [System].  This  effort  shall 
continue  through  the  fielding  of  the  final  version  of  the  last  block  release. 

The  above  shall  be  accomplished  in  three  distinct  phases: 

•  Phase  1  -  Requirements  Engineering  task  initiation  through  FSD  RFP  release 

•  Phase  2  --  FSD  RFP  release  through  contract  award 

•  Phase  3  -  Contract  award  through  final  fielding 

B.1.1  Phase  1  -  Requirements  Engineering  Task  Initiation  Through  FSD  RFP  Release 

During  this  phase,  the  RE  shall  establish  a  Requirements  Engineering  facility  and 
environment.  The  RE  shall  structure/revise  a  cohesive  plan  for  the  Requirements  Engineering 
needs  for  the  acquisition  and  ultimate  fielding  of  [System],  performing  whatever  risk  assessments 
that  are  necessary.  The  RE  shall  implement  this  plan.  The  RE  shall  verify  that  all  requirements  are 
feasible,  consistent,  testable,  and  complete.  The  RE  shall  interact  with  the  PM,  CD  and  system 
stakeholders  to  establish  a  feasible  and  acceptable  system  Functional  Baseline  (FBL)  of  [System], 
documenting  it  in  the  SSS.  The  RE  shall  host  the  [System]  System  Requirements  Review  (SRR). 
The  RE  shall  prepare  and  submit  technical  reports  and  construct  prototypes  as  required.  A 
Requirements  Engineering  Notebook  shall  be  developed  and  maintained,  documenting  the 
development  and  evolution  of  the  system  requirements.  The  RE  shall  support  the  incremental  block 
release  strategy  for  [System]  that  is  approved  by  the  PM  and  CD. 
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B.  1.2  Phase  2  -  FSD  RFP  Release  Through  Contract  Award 


Throughout  this  phase,  the  RE  shall  maintain  the  SSS,  effecting  necessary  minor  revisions, 
prior  to  the  receipt  of  best-and-final  offers  for  contract  award  for  the  initial  block  of  [System].  The 
RE  shall  also  begin  refining  and  documenting  system  requirements  for  subsequent  blocks,  utilizing 
the  procedures  employed  and  interfaces  defined  for  Block  1  requirements. 

B.1.3  Phase  3  -  FSD  Contract  Award  Through  Final  Fielding 

Throughout  this  phase,  the  RE  shall  assist  the  PM  in  monitoring  the  FSD  of  the  [System] 
for  requirements  compliance.  The  RE  shall  identify  discrepancies  and  anomalies  between  the 
system  requirements  and  the  system  in  development,  recommending  appropriate  resolution  when 
possible.  Tlie  RE  shall  trace  the  evolving  requirements  to  source  documents.  The  RE  shall  create 
the  requirements  testing  plan  and  cases  and  he  shall  perform  the  actual  testing.  The  RE  shall 
provide  the  PM  with  insight  on  the  cost,  schedule,  and  quality  impacts  of  requirements  changes  and 
evolution.  The  RE  shall  be  responsible  for  the  documentation  of  new  or  changed  requirements 
through  Engineering  Change  Proposals  (ECPs)  to  the  FBL. 

The  RE  shall  maintain  close  liaison  with  the  CD  and  available  end  users  to  identify  any  new 
or  potential  changes  to  the  system  requirements.  He  shall  provide  them  with  insight  on  the 
feasibility  and  impact  of  new  requirements  or  requirements  changes. 

The  RE  shall  provide  technical  support  to  the  project’s  Configuration  Control  Board  to 
review  proposed  changes.  He  shall  support  the  CD  in  preparation  of  plans  for  field  testing. 

The^RE  shall  answer  the  requirements  related  questions  of  the  FSDC. 

B.2  Detailed  Requirements 

The  RE  shall  devise  and  implement  processes  ior  managing  and  performing  all 
Requirements  Engineering  activities.  Required  engineering  processes  shall  include,  but  may  not  be 
limited  to  the  following: 

•  Develop/  purchase  and  maintain  a  Requirements  Engineering  environment. 

•  Assess  and  manage  risk. 

•  Perform  system  requirements  analysis  and  studies. 

•  Develop  System/Segment  Specification. 

•  Perform  System  Requirement  Review. 

•  Trace  requirements. 

•  Assess  requirement  changes  and  evolution. 

•  Create  the  requirements  test  plan,  cases,  and  perform  the  testing. 

•  Monitor  FSDC  compliance  with  requirements. 

•  Interact  with  the  FSDC. 
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•  Perform  system  requirements  analyses  for  block  releases. 

(Note:  These  processes  may  overlap  and/or  be  applied  iteratively/recursively.) 

B.2.1  Develop  and/or  Purchase  and  Maintain  an  Automated  Requirements  Engineering 
Environment 

With  [Agency]  approval,  the  RE  shall  develop  or  purchase  Requirements  Engineering 
software  and  hardware  as  required  to  identify  and  elicit  requirements;  evaluate  requirements 
feasibility  and  alternatives;  document  requirements;  trace  requirements  to  source  documents;  and 
communicate  with  the  CD  and  PM  in  requirements  refinement  and  validation.  The  RE  shall 
maintain  the  software  and  hardware  associated  with  the  Requirements  Engineering  environment 
throughout  the  life  of  the  contract  and  they  shall  be  delivered  to  the  [Agency]  at  contract 
completion. 

B.2.1.1  Configuration  Management 

The  RE  shall  perform  configuration  management  of  the  Requirements  Engineering 
environment  in  compliance  with  the  guidance  found  in  MIL-STD-483  and  supplements  thereto. 

B.2.2  Assess  and  Manage  Risk 

The  RE  shall  establish  and  implement  procedures  for  risk  assessment  that  effectively 
identify,  analyze,  monitor,  and  mitigate  areas  of  the  [System]  procurement  that  involve  potential 
requirements  related  cost,  schedule,  or  quality  risks.  They  shall  be  documented  in  technical  reports. 

The  RE  shall  establish  and  implement  procedures  for  controlling  risk  to  include: 

a.  Identifying  the  risk  areas  of  the  procurement  and  the  risk  factors  in  each  area. 

b.  Assessing  the  risk  factors  identified,  including  the  probability  of  occurrence  and  the 
potential  impact  to  cost,  schedule,  and  quality. 

c.  Identifying  and  analyzing  the  alternatives  available  for  reducing  the  risk  factors. 

d.  Proposing  the  most  promising  alternative  for  each  risk  factor. 

e.  Obtaining  feedback  to  determine  the  success  of  the  risk  reducing  action  for  each  risk 

factor. 

B.2.3  Perform  Systems  Requirements  Analysis  and  Studies 

B.2.3. 1  Requirements  Engineering  Planning 

The  RE  shall  develop/revise  and  maintain  plans  for  the  conduct  of  all  activities  required  by 
this  SOW  in  a  document  entitled  the  Requirements  Engineering  Plan  (REP).  The  format  and 
content  of  this  plan  is  provided.  (See  Appendix  C.) 


B.2.3.2  Apply  Requirements  Engineering  Techniques  to  the  Development  of  System 
Requirements 

The  RE  shall  perform  and  document  trade-off  analyses  of  alternatives  for  optional 
requirements. 

The  RE  shall  apply  Requirements  Engineering  techniques  and  technology  to  develop  the 
FBL,  from  mission  needs  statements  and  other  high  level  requirements  documents  to  its  validation. 
The  RE  shall  elicit  and  confirm  the  system  requirements  with  all  system  stakeholders.  The  RE  shall 
insure  that  all  requirements  are  feasible,  consistent,  and  testable. 

The  RE  shall  propose  and  develop  a  block  release  strategy  for  the  system.  The  block 
release  strategy  shall  ensure  that  the  initial  block  release  provides  a  set  of  capabilities  that  is 
approved  by  the  PM  and  CD. 

B.2.3.3  Requirements  Engineering  Notebooks 

The  RE  shall  document  all  Requirements  Engineering  efforts,  participants,  information, 
and  sources  of  information  in  the  Requirements  Engineering  Notebook  which  shall  be  in  a  format 
proposed  by  the  RE  and  subject  to  [Agency]  approval.  The  RE  shall  utilize  this  notebook  to  provide 
an  audit  trail  of  his  activities. 

B.2.4  Develop  System/Segment  Specification 

B.2.4.1  System/Segment  Specification 

The  RE  shall  prepare  and  maintain  the  SSS  for  the  [System]  which  shall  document  all 
planned  block  releases.  The  initial  SSS  shall  completely  specify  the  requirements  for  the  block  1 
release  and  it  shall  be  adequate  for  the  solicitation  and  subsequent  development  of  the  first  block 
of  [System].  This  SSS  shall  identify  each  subsequent  block  release  to  the  level  of  detail  possible  at 
this  time.  The  RE  shall  subsequently  maintain  the  SSS  to  reflect  the  evolving  requirements  of  this 
system. 

B.2.4.2  User  Interface  and  Interaction  Specification 

The  RE  shall  identify  and  document  the  user  system  interface  and  interaction  requirements 
at  the  same  level  as  interfaces  to  external  systems.  Proposed  content  for  this  section  is  provided. 
(See  Appendix  D.) 

B.2.4.3  Test  Architecture 

Section  4  of  the  SSS  shall  propose  a  test  architecture  for  the  system  quality  assurance 
provisions.  The  architecture  shall  be.developed  in  concert  tith  the  designated  test  oiganization  and 
shall  address  the  system  test  philosophy.  The  architecture  shall  identify  the  resources  that  shall  be 
required  for  system  testing,  including  operational  and  test  hardware  and  software.  The  architecture 
shall  include  the  test  evaluation  criteria  below: 


Traceability 


•  Consistency  with  requirements. 

•  Adequacy  of  test  cases/test  procedures. 

B.2.5  Perforin  System  Requirements  Review  (SRR) 

The  RE  shall  conduct  the  SRR  in  accordance- with  MIL-STD-1521.  The  RE  shall  present 
the  SSS  at  the  SRR  for  validation.  The  RE  shall  ensure  that  all  changes  approved  at  the  SRR  are 
incorporated  in  the  revised  SSS. 

When  incremental  block  FBL’s  are  sufficiently  defined  and  ready  for  implementation,  the 
RE  should  host  the  SRR  for  it.  This  review  shall  address  new  requirements,  changes  to  old 
requirements,  and  compatibility  issues  between  blocks. 

The  RE  shall  provide  the  PM  with  minutes  for  all  SRR’s. 

B.2.6  Trace  Requirements 

The  RE  shall  trace  all  requirements  from  the  high  level  source  documents  initially  provided 
to  the  SSS.  This  tracing  shall  be  implemented  in  an  automated  database  and  shall  be  expandable  to 
include  design  related  detail.  (The  RE  shall  trace  the  requirements  to  the  following  FSD 
deliverables: ...) 

The  RE  shall  provide  traceability  of  requirements  changes. 

B.2.7  Assess  Requirements  Changes  and  Evolution 

The  RE  shall  evaluate  all  proposed  changes  identified  by  the  PM/CD  as  to  their 
completeness,  accuracy,  consistency,  and  testability  and  shall  apply  Requirements  Engineering 
technology  as  necessary  to  refine  the  requirements.  The  RE  shall  assess  the  cost,  schedule,  and 
quality  impact  of  the  changes  and  make  recommendations  on  whether  the  changes  should  be 
included  in  the  current  block  release  or  a  subsequent  block  release. 

B.2.8  Create  the  requirements  test  plan,  cases  and  perform  the  testing. 

The  RE  shall  create  the  requirements  test  plan  and  test  cases  for  all  releases  that  are 
delivered  by  the  FSDC.  They  shall  be  documented  in  test  plan  and  description  documents  per  DI- 
MCCR-80014A  and  DI-MCCR-80015A.  The  RE  shall  perform  all  requirements  related  tests.  The 
RE  shall  document  the  results  of  the  tests  in  a  test  report,  per  DI-MCCR-80017A. 

B.2.9  Monitor  FSDC  Compliance  With  Requirements 

The  RE  shall  support  the  [Agency]  in  the  review  of  the  FSD  effort  to  verify  that  the  design 
and  implementation  is  consistent  with  approved  requirements.  The  RE  shall  review  all  FSDC 
deliverables  for  requirements  compliance;  and  attend  progress  review  and  formal  design  review 
meetings.  The  RE  shall  identify  discrepancies  and  anomalies  between  the  system  requirements  and 
the  system  in  development,  recommending  appropriate  resolution  when  possible. 
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B.2.9.1  Corrective  Action  Process  (CAP) 

The  RE  shall  establish  and  maintain  a  CAP  for  all  requirements  related  problems  detected 
in  items  under  development  or  configuration  control.  This  process  shall  be  closed-loop,  ensuring 
that  all  detected  problems  are  promptly  reported  and  entered  into  the  ECP  process,  actions  are 
initiated  on  them,  resolutions  are  achieved,  status  is  tracked  and  reported,  and  records  of  the 
problems  are  maintained  in  the  Requirements  Engineering  Notebook  for  the  life  of  the  contract. 
The  RE  shall  prepare  reports,  as  required.  The  RE  shall  classify  each  problem  identified  by 
category  (i.e.,  requirements,  code,  design,  etc.)  and  by  priority  (i.e.,  high,  medium,  and  low);  and 
perform  analyses  to  detect  adverse  trends  in  the  problems  reported.  The  RE  shall  closely  monitor 
the  FSD  effort  to  verify  that  problems  have  been  resolved,  adverse  trends  have  been  reversed, 
changes  have  been  correctly  implemented  in  the  appropriate  FSDC  processes  and  products,  and  no 
additional  problems  have  been  introduced. 

B.2.10  Interact  with  the  FSDC 

The  RE  shall  support  the  FSDC  by  answering  requirements  related  questions,  seeking 
clarification  from  the  CD  when  necessary.  The  RE  shall  report  all  queries  and  his  responses  to  the 
PM. 

B.2.11  Perform  System  Requirements  Analysis  for  tilock  Releases 

The  RE  shall  apply  Requirements  Engineering  techniques,  tools,  and  methodologies  to 
define,  refine,  and  document  the  evolving  requirements  of  block  releases  in  concert  with  the  PM 
and  CD.  The  RE  shall  solicit  and  record  user  feedback  on  their  experience  with  fielded  releases  to 
clarify  and  define  the  evolving  requirements.  The  RE  shall  revise  the  SSS,  using  ECPs  to  reflect 
the  evolving  requirements.  Later  blocks  have  the  added  constraint  that  they  must  be  compatible 
with  fielded  blocks.  The  RE  shall  repeat  the  relevant  activities  in  this  SOW  for  each  block  release. 

B.3  Reporting 

B.3.1  Monthly  Status  Reports 

The  RE  shall  submit  monthly  status  reports  identifying  the  status  of  the  development  of  the 
requirements;  the  areas  addressed;  the  stakeholders  that  have  been  contacted;  the  requirements  that 
have  been  identified;  issues  that  have  been  clarified;  and  any  problems  that  have  been  encountered. 
This  status  report  shall  also  contain  information  on  personnel  assigned  during  the  reporting  period; 
personnel  expected  to  be  assigned  next  reporting  period;  travel  completed  this  period;  travel 
anticipated  next  period;  costs  during  this  period,  cumulative  through  this  period,  and  projected  for 
next  period;  and  anticipated  activities  for  the  next  period. 

B.3.2  Quarterly  Progress  Reviews 

The  RE  shall  conduct  quarterly  progress  reviews  describing  all  the  efforts  of  the  previous 
quarter.  All  areas  addressed  in  the  Monthly  Status  Reports  shall  be  discussed,  but  on  a  quarter-wide 
basis. 
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B.4  Deliverables 


B.4. 1  Prototypes,  Models,  Simulations,  and  Tools 

By  the  end  of  this  contract,  the  RE  shall  deliver  all  prototypes,  models,  simulations,  and/or 
tools  generated  in  the  process  of  developing  the  [system]  requirements.  They  shall  be  delivered, 
with  documentation,  as  proposed  by  the  contractor  and  approved  by  [Agency],  and  with  unlimited 
rights  to  the  Government.  The  RE  shall  ensure  that  the  systems  and  documentation,  as  delivered, 
are  sufficient  to  allow  each  item  to  be  installed  and  executable  on  a  commercially  available 
Government  owned  host  computer.  The  RE  shall  insure  that  sufficient  documentation  and  special 
purpose  hardware/software  are  provided  to  enable  the  Government  to  run  and  modify  all 
prototypes.  [Note:  Serious  consideration  should  be  given  as  to  whether  the  need  for  acquiring  the 
above  justifies  the  potential  costs.] 

All  hardware  and  software  that  was  purchased  by  the  RE  with  contract  funds  shall  be 
delivered  to  the  [Agency]  at  the  end  of  this  contract. 

B.4.2  System/Segment  Specification 

The  RE  shall  finalize  and  deliver  the  SSS  for  the  [System].  The  initial  SSS  shall  be 
presented  at  a  System  Requirements  Review  for  validation.  The  revised  SSS  shall  be  delivered  for 
use  in  the  [System]  acquisition.  The  RE  shall  maintain  this  document  throughout  the  life  of  this 
contract,  providing  the  PM  with  the  latest  version  upon  request. 

B.4.3  Requirements  Test  Plan 

The  RE  shall  develop  a  requirements  test  plan  for  all  releases  of  the  objective  system.  It 
shall  be  in  the  format  of  DI-MCCR-80014A.  These  plans  shall  be  provided  (#  months)  prior  to  the 
Govemments’s  acceptance  testing  of  the  FSDC  system  releases. 

B.4.4  Requirements  Test  Description 

The  RE  shall  specify  the  requirements  related  test  cases.  They  shall  be  documented  in  the 
format  of  DI-MCCR-80015A.  They  shall  be  provided  (#  months)  prior  to  acceptance  testing  of  the 
FSDC  system  releases. 

B.4.5  Requirements  Test  Report 

The  RE  shall  document  the  results  of  all  requirements  related  tests  that  he  performs.  They 
shall  be  in  the  format  of  DI-MCCR-80017A.  They  shall  be  provided  within  (#)  days  of  the  tests. 

B.4.6  Requirements  Engineering  Notebook 

The  RE  shall  develop  and  maintain  the  Requirements  Engineering  Notebook,  providing  an 
audit  trail  on  the  development  of  the  [System]  requirements.  This  notebook  shall  be  available  to 
the  PM  at  any  time  for  inspection,  reference,  and  reproduction.  This  notebook  shall  be  delivered  to 
the  [Agency]  at  the  end  of  the  contract. 
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B.4.7  Technical  Reports 

The  RE  shall  provide  RE  technical  reports  as  required  in  a  mutually  agreed  upon  format. 
B.4.8  Minutes  of  the  SSR 

The  RE  shall  provide  the  PM  with  minutes  of  all  SRR’s  that  are  hosted. 

B.4.9  Monthly  Status  Reports 

The  RE  shall  submit  Monthly  Status  Reports. 

B.5  Constraints 

By  selection  as  the  RE  for  the  [System],  the  RE  shall  be  precluded  from  bidding  on  future 
FSD  efforts  for  the  [System].  In  addition,  the  RE  shall  be  precluded  from  subcontracting  to  perform 
work  for  the  FSD  effort. 
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Appendix  C 


REQUIREMENTS  ENGINEERING  PLAN  FORMAT  AND  CONTENT 


This  appendix  provides  the  format  and  content  of  a  Requirements  Engineering  Plan.  This 
plan  provides  the  Requirements  Engineering  approach  and  identifies  all  activities,  schedules,  tools, 
and  resources  that  will  be  used  in  the  Requirements  Engineering  effort. 

Since  the  Acquisition  Model  can  be  tailored,  not  all  sections  of  this  document  may  be 
applicable  to  a  specific  project. 

C.l  Requirements  Engineering  Activities 

C.1.1  Systems  Requirements  Analysis. 

This  specifies  the  approach  for  performing  the  objective  system’s  requirements 
analysis.This  should  discuss  the  plans  and  schedule  for  interaction  with  the  stakeholders 
throughout  the  life  cycle  of  the  effort. 

C.1.2  Risk  Assessment. 

This  section  addresses  the  specific  procurement  risk  assessments  that  will  be  performed  for 
the  objective  system. 

This  should  provide  a  plan  for  mitigation  of  risk  for  each  risk  area,  specifying  specific 
methods,  techniques,  and  tools. 

C.1.3  Alternative  Concepts  and  Trade-off  studies. 

This  section  addresses  the  specific  studies  that  are  needed.  This  will  include  the  aspects  of 
the  system  that  will  be  analyzed  and  the  criteria  that  will  be  used  in  making  trade-off  decisions 
between  conflicting  requirements. 

C.1.4  Systems  Requirements  Review. 

This  portion  of  the  plan  discusses  the  approach  for  the  Systems  Requirements  Review.  This 
should  include  criteria  for  passing  the  review  and  a  plan  for  the  validation  of  the  functional  baseline 
which  will  be  formed  as  a  result  of  this  review. 

C.1.5  Objective  System  RFP  Enhancements. 

This  section  identifies  the  products  that  will  be  developed  to  enhance  the  RFP  for  the 
objective  system.  This  should  minimally  include  the  SSS  and  a  recommended  tailoring  of  the  SOW 
and  CDRLs  of  the  objective  system. 
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C.1.6  Cost,  Schedule,  and  Impact  Estimation 


This  specifies  the  approach  for  preparing  cost,  schedule,  and  quality  impact  analyses  for 
proposed  changes  to  requirements  during  the  development  of  the  objective  system.  This  should 
discuss  the  measurement  of  the  uncertainty  of  the  estimates,  based  upon  the  uncertainty  of  the 
requirements.  This  section  should  also  describe  the  approach  for  coordinating  the  development  and 
data  management  efforts  to  ensure  interface  compatibility  and  maintainability. 

C.1.7  Requirements  Tracing. 

This  section  identifies  the  method  and  techniques  that  will  be  used  to  trace  the 
requirements. 

C.  1 .8  FSD  Contractor  Monitoring  Support. 

This  section  identifies  the  approach  and  extent  of  support  for  FSD  contract  monitoring  to 
insure  that  the  objective  system  is  in  compliance  with  system  requirements. 

C.1.9  Change  Management. 

This  section  identifies  the  approach  for  supporting  the  management  of  changes  to 
requirements.  It  should  include  change  request  procedures,  tracking  change  requests  and  their 
implementation,  and  trend  analysis. 

C.1.10  Systems  Analysis  for  Block  Releases. 

This  section  presents  the  approach  for  performing  system  analysis  for  requirements  during 
incremental  development. 

C.1.11  System  Requirements  Testing 

This  section  presents  the  approach  for  planning  the  system  requirements  tests,  specifying 
the  test  cases,  and  participation  in  the  actual  testing. 

C.2  Requirements  Engineering  Techniques 

C.2.1  Requirements  Engineering  Tools 

This  section  identifies  the  methodologies  and  tools  that  will  be  used  for  the  development, 
validation,  documentation,  and  management  of  requirements.  This  section  should  discuss  how  and 
when  they  will  be  used.  This  section  should  also  provide  the  rationales  for  their  selection.  Tools 
should  be  described  in  terms  of  vendor,  function,  operating  procedures,  operational  requirements, 
and  products.  When  applicable,  the  interaction  and  integration  of  divergent  tools  should  be 
discussed. 
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C.2.2  Prototyping. 


This  section  should  present  the  prototyping  approach.  It  should  address  the  approach  for 
identifying  those  aspects  of  the  system  that  need  to  be  prototyped.  This  section  discusses  the 
standards  for  the  development,  documentation,  and  delivery  of  any  prototypes  developed  during 
this  effort. 

C.2.3  Requirements  Engineering  Notebook. 

This  section  proposes  the  format  and  content  for  the  Requirements  Engineering  Notebook. 
The  notebook  should  be  constructed  in  such  a  way  as  to  provide  a  traceable  audit  trail  for  the 
development  and  evolution  of  the  system  requirements  for  all  Requirements  Engineering  activities 
and  products. 

C.3  Requirements  Engineering  Management 
C.3.1  Configuration  Management  Plan. 

This  section  identifies  the  plan  for  configuration  management  of  requirements  and 
Requirements  Engineering  products,  such  as  documents  and  prototypes.  This  should  address 
version  control  and  cross  referencing  between  versions  of  Requirements  Engineering  products; 
identification  procedures;  problem  and  change  reports  and  review  boards;  configuration  status 
accounting;  audits;  authentication  procedures;  and  major  milestones. 

C.3.2  Resources,  Organization  and  Staffing. 

This  section  identifies  the  resources,  organization,  and  staffing  plan  of  the  Requirements 
Engineering  effort,  describing  the  RE’s  facilities;  Government-furnished  equipment  and  services 
required;  and  organization,  personnel,  and  resources  for  Requirements  Engineering. 

C.3.3  Total  Quality  Management  (TQM). 

This  section  discusses  the  process  for  establishing  and  performing  Total  Quality 
Management  of  the  Requirements  Engineering  tasks.  TQM  requirements,  procedures,  evaluations, 
metrics,  internal  controls,  and  reports  utilized  should  be  specified.  This  should  also  address  the 
software  development  file;  associated  access  and  control  procedure;  and  procedures  and  reports 
used  to  prepare  for  formal  reviews. 

C.3.4  Technical  Status  Reviews  and  Reporting. 

This  section  specifies  the  approach  for  providing  detailed  status  reviews  and  reports  for  this 
effort.  This  must  include,  at  a  minimum,  problems  encountered,  technical  approaches,  technical 
status,  plans  for  future  work,  requirements,  cumulative  and  projected  costs,  and  schedule. 

C.3.5  Evaluation,  Testing,  and  Standards 

This  section  discusses  the  approach  for  evaluation  of  Requirements  Engineering  products, 
implementation  of  a  quality  evaluation  reporting  system,  format  of  all  test  documentation, 
corrective  actions  plan,  and  design  and  coding  standards. 
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Appendix  D 


USER  INTERFACE  SPECIFICATION 


This  appendix  provides  user  interface  and  interaction  requirements  for  a  typical  C2  system 
which  should  be  addressed  in  the  SSS.  This  includes  all  visual,  audio,  and  tactical  interfaces  and 
interactions. 

D.l  User  Interface  Hardware 

A  description  of  specified  capabilities  of  the  target  user  interface  hardware  for  the  system 
shall  be  specified,  including  quantitative  parameters  such  as  bandwidth,  response  and  access  time, 
and  storage  capacity.  The  interface  hardware  shall  include  but  not  be  limited  to  the  following: 

-  Number  of  independent  monitors  supported 

-  Description  of  monitor,  such  as  size,  number  of  pixels,  colors  bit  planes  etc. 

-  Description  of  keyboard,  such  as  number  of  function  keys,  keypad,  etc. 

-  Description  of  mouse  or  trackball,  such  as  number  of  buttons 

-  Audible  signal  capability 

-  Description  of  other  man-machine  interface  related  hardware,  such  as  scanners,  touch- 
panels,  special  displays,  etc. 

D.2  Screens 

D.2.1  Formats 

This  shall  define  every  class  of  screen  presentations,  including  menus.  The  formats  shall 
clearly  identify  screen  zones  and  their  purpose.  The  screen  definitions  shall  include  but  not  be 
limited  to  the  following: 

-  Use  of  multiple  windows.  If  used,  how  many,  window  moving  and  sizing,  when  is  a  new 
window  created,  etc. 

-  Screen  format,  including  reserved  zones,  placement  and  format  of  classification 
markings,  placement  of  titles,  icons,  menus,  buttons,  error  messages  etc. 

-  Window  format,  including  reserved  zones,  placement  and  format  of  classification 
markings,  placement  of  titles,  icons,  menus,  buttons,  error  messages,  etc. 

•  Use  of  color  and  their  meaning,  including  standard  colors  for  all  screen  components 

-  Use  and  type  of  fonts  for  every  class  of  presentation. 
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-  Vocabulary  form  and  standard  words  to  use  for  each  occasion.  For  example,  using  DONE 
to  indicate  job  is  completed  vs.  OK  or  EXIT 

-  Help  facilities,  indicating  the  standard  method  for  invoking  help,  and  the  format  and 
contents  of  the  help  displays 

-  Format  and  usage  of  menus,  buttons,  scroll  bars,  icons,  etc. 

-  Standard  interaction  sequences,  such  as  a  requirement  to  confirm  every  data  base  change, 
or  the  ability  to  undo  or  cancel  some  operations  after  they  have  been  initiated  or 
completed 

D.2.2  Presentations  and  Flows 

Pictures  of  all  screen  presentations  and  all  logic  flow  between  them  shall  be  specified, 
including  back-out  and  selection  sequences.  Interaction  between  the  state  of  the  system  and  screen 
flow  shall  be  specified. 

Screen  refresh  requirements  shall  be  specified,  indicating  whether  data  appearing  on  screen 
represents  information  accurate  only  at  the  time  the  screen  was  generated  or  whether  there  exists  a 
requirement  to  continually  update  presented  screen  data.  Refresh  rates  shall  be  specified,  if  needed. 

Density  of  screen  content  shall  be  specified,  defining  what  constitutes  operator  overload 
thresholds  that  mandate  screen  declutter.  Declutter  techniques  shall  be  specified. 

D.2.3  Data  Elements 

The  individual  data  elements  which  appear  on  the  screen  shall  be  specified,  providing  the 
meaning,  significance,  units,  and/or  data  type  of  each  data  element,  and  the  source  of  each  data 
element  whether  calculated  or  retrieved  from  internal  or  external  sources. 
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Appendix  E 


GLOSSARY  OF  TERMS  AND  ACRONYMS 

CAP  -  CORRECTIVE  ACTION  PROCESS 
CD  -  COMBAT  DEVELOPER. 

Command  or  agency  that  formulates  doctrine,  concepts,  organization,  material 
requirements,  and  objectives.  For  the  US  Army,  this  is  the  Training  and  Doctrine  Command 
(TRADOC).  May  be  used  genetically  to  represent  the  user  community  role  in  the  material 
acquisition  process. 

END  USER 


The  command  or  agency  which  will  ultimately  be  the  recipient  and/or  operator  of  a  system 
under  development. 

FSD  -  FULL-SCALE  DEVELOPMENT 

Normally,  the  phase  in  the  material  acquisition  process  during  which  a  system,  including 
all  items  necessary  for  its  support,  is  fully  developed. 

FSDC  -  FULL-SCALE  DEVELOPMENT  CONTRACTOR 
FBL  -  FUNCTIONAL  BASELINE 
See  DoD-STD-480. 

\ 

INCREMENTAL  DEVELOPMENT 

A  software  system  development  process  where  the  user  requirements  are  not  fully  known 
before  acquisition.  The  system  is  developed  in  a  series  of  partial  implementations.  Each 
implementation  is  used  to  clarify  and  refine  the  requirements  for  the  next  implementation. 

MILESTONE  0 


Program  Initiation/Mission-need  Decision,  approved  by  the  Defense  Acquisition  Board 
(DAB)  or  designated  authority,  which  determines  mission-need  and  approves  program  initiation 
and  authority  to  budget  for  a  new  program.  Normally,  a  concept  exploration/definition  phase 
follows  this  approval. 
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OBJECTIVE  SYSTEM 


The  system  under  consideration  for  development  for  which  Requirements  Engineering  is 
needed. 

PEO  -  PROGRAM  EXECUTIVE  OFFICER 


Individual  responsible  for  administering  a  defined  number  of  major  and/or  non-major 
acquisition  programs  who  reports  to  and  receives  direction  from  the  Army  Acquisition  Executive. 

PM  -  PROJECT  MANAGER 


Individual  chartered  to  conduct  business  on  behalf  of  the  Army  who  reports  to  and  receives 
direction  from  either  a  PEO  or  the  Army  Acquisition  Executive  and  is  responsible  for  the 
centralized  management  of  a  specified  acquisition  program. 

REQUIREMENTS 

Requirements  are  the  quantifiable  and  verifiable  behaviors  that  a  system  must  possess  and 
constraints  that  a  system  must  work  within  to  satisfy  an  organization’s  objectives  and  solve  a  set 
of  problems. 

RE  -  REQUIREMENTS  ENGINEER 

A  functional  entity  comprised  of  Government  and/or  contractual  personnel  that  performs 
the  Requirements  Engineering  tasks  required  by  the  PM. 

REP  -  REQUIREMENTS  ENGINEERING  PLAN 
REQUIREMENTS  ENGINEERING 

Requirements  Engineering  is  the  disciplined  application  of  scientific  principles  and 
techniques  for  developing,  communicating,  and  managing  requirements.  See  Appendix  B. 

RFP  -  REQUEST  FOR  PROPOSAL 
STAKEHOLDERS 

All  commands,  agencies,  or  personnel  who  are  difecdy  concerned  or  affected  with  the 
outcome  of  a  system  acquisition.  Stakeholders  may  include  the  end  user,  the  developing  agency, 
post  deployment  software  support  centers,  the  test  and  evaluation  agencies,  operational 
commanders,  logistics  support  agencies,  and  many  others,  depending  on  the  system. 
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SSS  -  SYSTEM/SEGMENT  SPECIFICATION 

A  system  level  requirements  specification  whose  format  is  specified  in  DoD  Data  Item 
Description  DI-CMAN-80008A. 

SRR  -  SYSTEM  REQUIREMENTS  REVIEW 
UNPRECEDENTED  SYSTEM 

A  system  which  does  not  parallel  a  system  which  has  been  previously  developed.  This  may 
be  due  to  the  planned  use  of  new  technologies,  a  new  mission-need,  a  need  that  has  never  been  met, 
or  a  significant  increase  over  previous  system  capabilities  and  performance. 
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Intensive  Efforts  Were  Devoted  To  Finding  The  Causes  Of  Software  Acquisition  Problems. 

Requirements  Related  Problems  Were  Frequently  Involved. 
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Proposed  Approach  -  An  Acquisition  Model 
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The  CECOM  CSE  Acquisition  Model  Stresses  Requirements  Engineering,  Emphasizing 
Techniques  For  Requirements  Definition  And  Change  Management. 

It  Recommends  Six  Risk  Reduction  Strategies,  Which  Can  Be  Tailored  To  Apply  To  A  Wide 

Range  Of  Acquisitions. 
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Designate  a  Requirements  Engineering  effort  which  applies  Requirements 
Engineering  techniques  from  the  early  project  phases  and  on. 
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Plan  to  develop  systems  in  an  incremental,  evolutionary  manner. 
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The  CECOM  CSE  Acquisition  Model  Stresses  Requirements  Engineering,  Emphasizing 
Techniques  For  Requirements  Definition  And  Change  Management. 

It  Recommends  Six  Risk  Reduction  Strategies,  Which  Can  Be  Tailored  To  Apply  To  A  Wide 
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